Debugging in a production environment is advantageous. First of all, a support team can dive into a potential defect right away with little preparation efforts. As a result, a defect may be detected and removed at the soonest opportunity, thereby significantly improving system performance.
Second of all, debugging in the same environment where a potential defect resides reduces or eliminates uncertainties inherently associated with debugging in a simulated—but different—environment. Because setting up a simulated environment may introduce other factors that were not present in the production environment, thereby complicating the debugging efforts. For example, a network performance difference between a production environment and a simulated environment may lead to an incorrect conclusion that a system failure was network performance related, when it was not.
Difficulties abound for debugging in a production environment, however. One technical problem is that, sometimes, production data are quite large in size and thus cannot be duplicated for debugging purpose without significant efforts. For example, replicating an entire enterprise database in order to debug an enterprise data processing application can be quite time- and resource-consuming and thus in some cases simply not possible.
Another technical problem is that, in some other cases, corporate data access control policies prohibit access to production data by outside development teams, even for testing and debugging purposes. As a result, an outside support team cannot even access a production environment, let alone running test cases and debugging errors.
There is therefore a need for improved techniques to debug in a production environment.